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(54) Method for sharing network resources by virtual partitioning 



(57) A method shares resources associated with 
various classes among calls in the various classes ac- 
cording to a state dependent reservation parameter. 
Nominal amounts of one or more resources are allocat- 
ed to each call class. When a call of a class of service 
operating in a network requires resources in excess of 
those allocated to the class, resources allocated to other 
classes of service are advantageously shared with the 
class of service. The sharing is based on a reservation 
parameter associated with the class of service of the 



call. The reservation parameter is advantageously a 
function of the network state. The role of the reservation 
parameter is to protect underloaded classes (i.e., those 
classes not using all of their allocated nominal capacity) 
from excessive borrowing by overloaded classes (i.e., 
classes using more than their allocated nominal capac- 
ity). More generally, the inventive method is used to de- 
termine if sufficient resources are available for routing 
calls and to route calls based on the determined avail- 
able resources. 
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Description 
Technical Field 

5 The invention relates to the field of sharing resources in a network, as for example by sharing bandwidth between 

different classes of services on a communications link in a network. 

Background 

10 Networks are a principal means of exchanging or transferring information (e.g., signals representing data, voice, 

text or video) among endpoints (e.g., devices for sending and/or receiving information such as computer terminals, 
multimedia workstations, fax machines, printers, servers, telephones) connected to the network. The exchange or 
transfer of information is often referred to as a "cair or "connection." A network comprises nodes connected to each 
other, and to endpoints, by links. Typically, each link is bi-directional, and thus information may be exchanged or trans- 

is ferred (i.e., the call may be carried) in forward and reverse directions. Each link is characterized by a bandwidth or link 
capacity in each direction. Information to be exchanged between two endpoints is conveyed over a path comprising a 
set of nodes and links connecting the two endpoints. Information in transit between endpoints may be temporarily 
stored in buffers at nodes along the path pending sufficient available bandwidth on links. 

Networks are increasingly being used for the reliable, high-speed transmission of information in digital format 

20 between endpoints. This increased use is bringing major changes in network architecture/infrastructure design, in 
network operations and in the classes of services (e.g., video-on-demand and video teleconferencing) offered to users 
at the endpoints. In particular, network operation must be efficient in terms of allocating resources (e.g., assets such 
as capacity in links and buffer space in nodes) in a network among the classes of services (invoked by users at end- 
points) competing for network resources. Efficient allocation of network resources can ensure that a network operates 

25 at high capacity (i.e., the network accommodates a large amount of information in transit through the network) thereby 
extracting high amounts of revenue from endpoint users. At the same time, the efficient allocation of resources will 
also take into account any quality of service commitments (e.g., guaranteed bandwidth or maximum information loss 
probability) made to endpoint users invoking the classes of services. 

One way to increase network efficiency involves sharing network resources. Various techniques for sharing re- 

30 sources have been considered. For example, one technique permits indiscriminate or complete sharing of network 
resources among various classes of services. Under the complete sharing technique, however, it is possible for one 
class of service to overwhelm all others, i.e., the one class of service uses all available resources, so that in some 
sense, the sharing is not fair. In another sharing technique, called complete partitioning, the physical elements that 
underlie the resources (e.g., the cable that supports a given bandwidth or capacity for carrying information or the 

35 memory devices that form the buffers in a node) are partitioned or allocated among the various classes of services, 
allowing each service exclusive use of its allocated resources. Under the complete partitioning technique, however, 
unused resources assigned to one class of service may not be used by another class of service and thus efficiency of 
the network is lowered. 

A technique intermediate between the complete partitioning and complete sharing techniques is physical partition- 

40 ing (PP). In the PP technique, as in the complete partitioning technique, the physical elements that underlie the resource 
are divided among the classes of services. However, sharing is permitted. Each sublink is then assigned a trunk (or 
sublink) reservation parameter. Calls of each class have priority in using capacity available within their allocated sublink. 
A call arriving at the sublink allocated to its class is accepted if the available capacity on the link (equal to the link 
capacity minus the capacity used by calls in progress through the link) is sufficient to carry the call. If there is not 

45 sufficient available capacity, then in accordance with some discipline or criterion, another sublink is chosen for carrying 
the call. To carry the call, the other chosen sublink must have available capacity which exceeds the sum of the capacity 
required by the call plus the sublink reservation parameter assigned to the link, i.e., the available capacity must be 
sufficiently in excess of the reservation parameter to carry the call. The sublink reservation parameter is designed to 
protect the sublink from having its capacity used by calls from other classes to such a point that calls from the class 

50 of service associated with the sublink are blocked or not accepted for routing. If no such other sublink exists, the call 
is lost. The simplest discipline picks the other sublink at random. Other disciplines for selecting alternate sublinks are 
based on the network state (which reflects utilization of network resources such as available capacity in links and 
available buffer space in nodes). See, Martin I. Reiman, "Optimal Trunk Reservation for a Critically Loaded Link," 
Teletraffic and Datatraffic, A. Jensen and V.B. Iverson (eds), Elsevier Science Publisher, North Holland (1991); K.W. 

55 Ross, "Multirate Loss Models for Broadband Telecommunication Networks," Springer 1995. 

The PP technique is advantageous in that it offers some protection to each class of service (because, unlike the 
complete sharing technique, calls of each class have an associated sublink at which they receive priority) while at the 
same time making more efficient use of the resource (because, unlike the complete partitioning technique, it allows 
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some sharing). However, PP techniques have some undesirable characteristics. 

To illustrate, consider a situation in which calls of a first class of service dominate usage, not only at a resource 
assigned or allocated to the first class, but also at a resource assigned to a second class of service. If the resource is 
capacity in a sublink, the situation may be due to a sudden burst of calls in the first class. In this, situation, a call from 
s the second class may be denied access to the resource assigned to the second class. In other words, the amount of 
available resource in the resource assigned to the second class may be insufficient to accommodate the call from the 
. second class due, in part, to utilization of the resource assigned to the second class by calls from the first class. 
Moreover, if the call of the second class attempts to use any resources assigned to the first class that may have become 
available, the available resources must be sufficient not just to accommodate the call of the second class, but to ac- 
10 commodate the call so that the available resources exceed the sublink reservation parameter. 

Note, however, that the sublink reservation parameter is a factor only when calls from one class attempt to use 
resources allocated to calls from another class. In the situation above, if a call of the first class comes in, it will be given 
priority at the resources assigned to calls of the first class, i.e., no sublink reservation parameter is used. Thus, even 
though calls of the first class dominate resources assigned to calls of the second class, a call from the first class may 
is be accepted and a call of the second class may be blocked or rejected. Thus, the PP technique may accentuate or 
propagate unfairness in sharing resources. 

Thus there is a need for improved techniques for sharing network resources. 

Summary 

20 

|| The present invention is directed to the above described types of methods in which a call of a class of service 

operating in a network requires resources in excess of those allocated to the class and where other resources, beyond 
those allocated to the class, are advantageously shared with the class of service. However, in accordance with the 
present invention, the sharing is based on a reservation parameter associated with the class of service of the call. The 

25 reservation parameter associated with a particular class represents the amount of the resources in the network that 
cannot be borrowed by the particular class when the particular class is using resources in excess of those allocated 
to the particular class. As such, the reservation parameter protects other classes from excessive borrowing by the 
particular class. The reservation parameter is advantageously a function of the network state. 

The reservation parameter can be used to determine if sufficient resources are available so that a particular call 

30 associated with a given class of service may be routed through the network on a path comprising nodes and links. A 
path on which the call can be routed can be determined by identifying those links, and the nodes between them, in the 
network which have the resources to and are capable of accepting the call. Those links are identified where either: 1) 
the particular call and other calls in the given class do not require link resources in excess of those allocated to the 
given class and where the link has sufficient resources to accommodate the call or 2) where the particular call and the 

35 other calls in the given class do require link resources in excess of those allocated to the given class and where the 
given class may share, in accordance with a reservation parameter associated with the given class, link resources 
allocated to other classes. The identified links may be used to generate a set of paths on which the call may be routed, 
and a particular path for routing the call is selected based on a criterion. 




Brief Description of the Drawings 



FIG. 1 illustrates a network in which the inventive method may be practiced. 
FIG. 2 illustrates a portion of the network of FIG. 1. 

FIG. 3 is a flowchart of steps in the inventive method for determining whether a link may accept or reject a request 
45 to route a call. 

FIG. 4 is a graph illustrating the dependence of call priorities with the state of the network. 
FIG. 5 is a flowchart of steps for routing a call through a distributed network using the inventive method. 
FIG. 6 illustrates a centralized network in which the inventive method may be practiced. 
FIG. 7 is a flowchart of steps for routing a call through a centralized network using the inventive method. 
50 FIG. 8 is a flowchart of step in the inventive method for determining whether a link may accept or reject a request 

to route a call in a virtual private network. 

Detailed Description 

ss FIG. 1 illustrates a network in which the inventive method for sharing network resources by virtual partitioning may 

be practiced. Network 110 comprises nodes 130-/ and links 140-a Each link has associated with it a respective band- 
width capacity. Information is input to the network from endpoints 150-m. when information is to be exchanged or 
transferred between endpoints (i.e., when a call is made between an initiating endpoint and a destination endpoint), 
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the initiating endpoint makes a request that a path for carrying the call be established in the network between the two 
endpoints. For example, one possible path over which a call may be carried between endpoints 105-1 and 105-2 
comprises nodes 130-1, 130-2 and 103-3 and links 140-1, 140-3, 140-5 and 140-7. Selecting a particular path to carry 
a call (i.e., routing a call) through the network requires that the nodes and links in the particular path have sufficient 
s available resources. 

The inventive method is a technique for sharing network resources fairly and efficiently between classes of services 
so as to enable paths for carrying calls to be established in a network. In the inventive method a call is assigned to a 
class according to the type of service the call invokes. The sharing is constrained to be both "fair" and "efficient. " In 
other words, the sharing is such that a given quality of service commitment for each class of call can be achieved (the 

io "fairness" constraint) while at the same time ensuring that one or more network resources are not underused (the 
"efficiency" constraint). The fairness constraint is reflected in the inventive method in that some resources are allocated 
to each call class, while the efficiency constraint is reflected in that some sharing of the allocated resources is permitted. 
The sharing in the inventive method is termed "virtual partitioning" because, unlike physical partitioning, no particular 
physical elements that provide the basis for the resources are dedicated or specifically associated with any class. 

75 in the inventive method nominal amounts of one or more resources are allocated to each call class, advantageously 

in such a way that a given quality of service requirement can be achieved. Resources are shared as a function of the 
network state (i.e., as a function of the current utilization of the one or more network resources by the various classes). 
The network state is reflected in a varying (or dynamic) reservation parameter for each class. That is, instead of each 
class of traffic having a fixed priority or reservation parameter, as in traditional trunk reservation schemes, the priorities 

20 depend on the state of the system and thus will vary with changes in the numbers of calls of each class. The role of 
the reservation parameter is to protect underloaded classes (i.e., those classes not using of all their allocated nominal 
capacity) from excessive borrowing by overloaded classes (i.e., classes using more than their allocated nominal ca- 
pacity). More generally, the inventive method may be used to determine if sufficient resources are available for routing 
calls and to route calls based on the determined available resources. 

25 Use of the inventive method is demonstrated below in the portion of network 110 of FIG. 1 shown in FIG. 2. The 

inventive method is illustrated herein where the network resource to be shared is capacity on one or more links. How- 
ever, those skilled in the art will recognize the applicability of the inventive method to resources other than capacity. 
More specifically, the inventive method is illustrated where calls in Kclasses of service arrive from links 140-11 , 1 40-12 
and 140-14 at node 130-6 for subsequent transmission on link 140-15. Link 140-15 has capacity C. Each class of call 

30 is allocated a nominal capacity C k where 

k 

35 

and C k is sufficiently high to meet any quality of service guarantees for the k* h service. The nominal capacities may 
advantageously be assigned using techniques described in A. Elwalid, D. Mitra and R.H. Wentworth, "A New Approach 
for Allocating Buffers and Bandwidth to Heterogeneous Regulated Traffic in ah ATM Network," IEEE J. Sei. Areas 
Comm., Vol. 1 3, No. 6, pp. 1 1 1 5-1 1 27, August 1 995; application Serial No. 08/554502, filed November 7, 1 995, entitled 

40 "Method for Logical Network Design in Multi-Service Networks," by D. Mitra, J. Morrison and K. Ramakrishnan, incor- 
porated by reference herein. Let n k denote the number of calls of class k in progress on link 140-15. Let c^ be the 
bandwidth required for a call of class /con link 140-15. The variable d k may advantageously represent an effective 
bandwidth for a call of class k reflecting characteristics of the class such as burstiness and variability as well as quality 
of service requirements. Elwalid, supra. 

45 The arrival process of calls of class k, k=1 ,2,... K, is advantageously assumed to be a Poisson process (useful in 

describing many chance phenomena) where the arrival process is completely characterized by a rate parameter, X k 
Calls of class k advantageously have exponential holding times with respective means for each class. 

FIG. 3 illustrates the steps in the inventive method. In step 310 a request is received (e.g., by node 130-6) to route 
a call of class k requiring bandwidth d,, onto a link (e.g., link 140-15) of capacity C. In step 320 the inventive method 

so determines whether, if the call of class /c is accepted, if class /c will be "underloaded" or "overloaded." Class k will be 
underloaded if the number of calls of that class in progress through the link (n k ) plus the requested call have not used 
up all the capacity allocated to class k. The capacity used by the n k calls can be determined from knowledge of the 
number of calls in progress of the class n k and from knowledge of the bandwidth used by the individual calls. Alterna- 
tively, the capacity used can be determined by assuming that each call in class k requires bandwidth d k In this case, 

55 class Ac will be underloaded if n^d^C^. Still further, may be obtained by a process of direct measurements. The 
measurement process requires appropriate smoothing and averaging (over a small time interval) by techniques well 
known in the art. Class k will be overloaded if and only if the currently routed calls plus the requested call will use up 
all the nominal capacity allocated to class k. Again, if the bandwidth of each call in class k is assumed to be d^ class 
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k will be overloaded if n^^C^d^ There are two cases to be considered. In the first case, if the call is accepted on 
the link, class k is underloaded, and the "yes" branch of the decision box in step 320 is taken. Alternatively, in the 
second case, class k is overloaded if the call is accepted, and the n no n branch of the decision box in step 320 is taken. 

If the "yes" branch is taken, the inventive method next determines in step 340 if there is sufficient available capacity 
on the link to accept the call. In other words, the call can be accepted (step 360) if n<C-d k , where n denotes the amount 
of bandwidth already being used on the link by previously routed calls, e.g., 



If there is insufficient available capacity on the link, the call will be rejected in step 350. 

If the "no" branch is taken from the decision box in step 320, the inventive method then determines is there is 
is sufficient available capacity on the link to accept the call while protecting underloaded classes of calls. In other words, 
the call can be accepted on the link (step 360) if n<C-r k -d k , where n is as defined above and where r k denotes the 
reservation parameter which is applied to class k calls when class k is overloaded. The selection of r k is discussed in 
more detail below. If the available capacity is insufficient to protect underloaded classes, the call is rejected (step 350). 
The above inventive method may equivalently be stated in the following more compact form: 
20 accept a new call of class k if and only if: n^C-r^fn^^C^d^-dif 

I) Here 1 (x) is the indicator function which has value 1 if x is true and value 0 if x is false. 

As noted above, ^denotes the reservation parameter which is applied to class calls when class k is overloaded. 
The role of the reservation parameter is to protect the underloaded classes. Reservation works thus: when any under- 
loaded class becomes active and demands resources up to its nominal allocation, the reservation mechanism ensures 
25 that resources are made available in a timely manner. The specific value of r k is chosen so as to permit a large number 
of calls to be accepted while ensuring that calls in no class of service are blocked or rejected above a tolerable level. 
The choice of the numerical value of the reservation parameter is advantageously a monotonic increasing function in 
the amount of underloadedness. The selection of r k is discussed below. 
Consider 



£(a-n«A) 



keLJ 



to be representative of the degree of underloadedness in the link where U denotes the set of underloaded classes. 
Hence, let 



" = / 



£ (C* - mdk)\ Xk\ dk 



Aef/ 



45 where /[ ] is advantageously a slowly changing and montonically increasing function of the first argument of function 
f t such as log[ ]. The reservation parameter /> also advantageously depends on the rate of the arrival process of class 
k calls, increasing with increasing X fr on the mean holding time, 1/^ increasing with increasing ^/^l k , and on the 
bandwidth required by class k calls, d^ increasing with increasing d^ The reservation parameter r^is, typically in the 
range of 2 to 5% of the value of C. Another option is to have three values for 



Aef/ 



is large 
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is small 



f£ where f k i>r k2 >r k 3 . For example, r fr t r^and r^can be fixed values. 

FIG. 4 may be used to illustrate the aspect of dynamic priorities, i.e., of a state dependent reservation parameter, 
in the inventive method. In particular, FIG. 4 illustrates priority regions for a case where calls are of one of two classes, 
/c=1 or k=2, having respective nominal capacities C 1 and C 2 and respective reservation parameters r r and r 2 Calls in 
each class are carried on a linkof capacity C Axis 401 represents the amount of bandwidth used by n 1 calls of bandwidth 

20 d 1 in class 1 through the link of capacity C. Axis 402 represents the amount of bandwidth used by n 2 calls of bandwidth 
d 2 in class 2 through the link of capacity C. Since the link has capacity C, the total bandwidth used by the calls in each 
class cannot exceed C, i.e., the number of calls of class 1 and class 2 must satisfy the condition n 7 d 7 + n^i 2 < c 
Values of n 1 d 1 and n 2 d 2 which satisfy this condition are represented by points in the region formed by line 410 and 
axes 401 and 402. The region comprises five areas: 406, 407, 408, 420 and 421. 

25 Area 406 represents values of n 1 d 1 and n 2 d 2 where neither class is overloaded and thus no call class is given 

priority. Area 407 represents values of n 1 d 1 for which class 1 is overloaded and where, therefore, a reservation pa- 
rameter is used to protect calls of class 2 from being blocked. The reservation parameter plays a role when calls of 
class 1 arrive. Since class 1 is overloaded, the class will have to borrow or share resources (e.g., the nominal allocated 
capacity) associated with class 2. The sharing will only be allowed if resources beyond those reserved by the reservation 

30 parameter are available on the link to carry the call. The method ensures that sufficient spare capacity remains for 
calls of class 2 (the underloaded class) to be accommodated, rather than blocked or rejected, on the link. Thus, the 
amount of protection given to class 2 calls, and hence the size of area 407, will depend on the reservation parameter. 
Similarly, area 408 is the region in which class 2 is overloaded and where a reservation parameter is used to protect 
class 1 calls. Area 420 represents values of n-fdf where class 1 is overloaded but where no priority is given to class 2 

35 calls. The size of area 420 depends on r v The value of r 1 is advantageously selected to be sufficiently high so as to 
provide protection to underloaded classes but not so high as to cause the inventive method to be overly conservative 
in blocking class 1 calls (i.e., to be overly conservative in borrowing resources from other classes) when class 1 is 
overloaded. Similarly, area 421 represents values of n^d 2 where class 2 is overloaded but where no priority is given 
to class 2_calls. Thus, depending on the state of how resources are used in the link, i.e., on the value of n 1 d 1 and 

40 the priority given to a class of call can be determined. Moreover, the priority given to a class of call may vary as n 1 and 
n 2 change. 

The above technique, which focused on determining whether a single link can accept or reject a call, can be applied 
to all links in a network so as to select a path on which to route a call between two endpoints. Consider again network 
110 of FIG. 1. Network 110 is a distributed or decentralized network in that routing decisions are made locally. Each 

45 node 130-/in network 110 periodically exchanges state information (i.e., information relating to network topology and 
the allocation and usage of network resources) with neighboring nodes. The state information thus reflects the amount 
of network resources available or in use on a link from a node to every neighboring node. Hence, paths through the 
network capable of carrying a call may be determined. Note, however, that unless the state information propagates 
quickly relative to the speed with which calls are initiated and terminated, the information will become dated. Thus, 

50 each node may have a different description or local view of the network state. This description is called the local network 
state. 

FIG. 5 illustrates steps for using the inventive method to select a path through a network on which a call may be 
routed. In step 510 a request to route a call of class k on a path through the network between a set of endpoints, 
comprising an initiating endpoint and a destination endpoint, is received (e.g., by the node directly connected to the 
55 initiating endpoint). In step 520, those links in the network capable of accepting or carrying the call of class k are 
identified. Step 520 may be executed using the steps in the inventive method as shown in FIG. 3 where the determi- 
nation of overloadedness or underloadedness and of whether sufficient available capacity exists is made based on the 
local network state. In step 530, the method identifies a set of paths between the set of endpoints wherein each path 
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in the set of paths consists only of identified links and the nodes between the identified links. In step 540, a path is 
selected from among paths in the set according to a criterion as the routing path for the call. An attempt is made to 
route the call on the selected path in step 550. 

In step 560 the method checks to see if the routing was successful. If it was, the method ends. If it was not suc- 
5 cessful, another path is selected and step 550 is repeated. An attempt at routing may not be successful because the 
information at the node may have used dated information to identify links capable of accepting or carrying the call. 
Thus, resources that the node expected to be available may not indeed be available, in which case the routing attempt 
will be unsuccessful. 

The criterion for selecting a path may be chosen for ease of implementation (e.g., the selection of a path from the 

io set of paths may be at random). In other cases, the criterion for selecting a path may be chosen so as enhance network 
operation with respect to one or more resources. For example, in the method of FIG. 3, if it is determined that a link 
can accept a call, a "cost" for accepting the call can be assigned to the link. The cost could reflect the extent to which 
the class is either overloaded or close to being overloaded, i.e., the higher the extent of overloading or the closer to 
being overloaded, the higher the cost. The selection of a path could then be a function of the cost, as for example, by 

is selecting the path whose links sum to the lowest cost. 

The inventive method may also be used in networks in which centralized routing decisions, rather than distributed 
or decentralized routing decisions, are made. FIG. 6 illustrates the structure of network 606 which is a centralized 
routing system in which the inventive method may be practiced. Endpoints 602-/ exchange or transfer information via 
network 606. Network 606 comprises nodes 608-p and links 660-/. Links 660-/connect nodes 608-pXo each other and 

20 to endpoints 602-/: Request processor 61 1 is connected to nodes 608-p and may be located within network 606. Since 
4fc all requests to route calls are processed in request processor 611 , request processor 611 has up-to-date knowledge 
of the network state. Thus, multiple attempts to select a path on which to route a call typically will not be necessary. 

Centralized routing systems are advantageous in that routing decisions are made with up-to-date state information. 
However, a centralized routing system is more likely to suffer from reliability problems than a decentralized system 

25 since a centralized routing system has a single point of failure (i.e., the request processor). Moreover, centralized 
routing systems typically have difficulty operating or communicating with other centralized routing systems since each 
of the systems typically will not have information about the state of the other system. Thus, additional protocols for 
arbitrating and communicating between centralized networks are required. Finally, since each node in centralized rout- 
ing system must first communicate with a device (such as a request processor), the propagation delay for communi- 

30 eating with such a device increases the time for establishing a call beyond the time required by a distributed system 
thereby increasing system overhead per call. 

Steps in the inventive method as used in the centralized routing system of FIG. 6 are shown in FIG. 7. In step 710 
request processor 611 receives a request to route a call of class /fona path through the network between a set of 
endpoints comprising an initiating endpoint and a destination endpoint. In step 720, those links in the network capable 

35 of carrying the call of class k are identified. Step 720 may be executed using the steps in the inventive method as 
shown in FIG. 3 where the determination of overioadedness/underloadedness and sufficient spare capacity is made 
based on the up-to-date network state information in request processor 611. In step 730, a set of paths between the 
set of endpoints is identified wherein each path in the set of paths consists only of identified links and the nodes between 
the identified links. In step 740, a path is selected, according to a criterion, from among paths in the set on which to 
route the call (step 750). Since all the links in the selected path capable of accepting the call were identified using up- 
to-date state information, the routing of step 750 should be successful. The criterion for selecting a path may be chosen, 
as above in the case of distributed routing, for ease of implementation or so as to enhance network operation with 
respect to one or more resources. 

The inventive method may also be used for sharing resources at different levels in a hierarchical network. In 

45 particular a hierarchical virtual partitioning method advantageously uses a reservation parameter at each level in the 
hierarchy to ensure fair and efficient sharing of resources at each level. The hierarchical virtual partitioning method is 
illustrated in the.context of a virtual private network (VPN). A private network is a network for the exclusive use of one 
customer. Such a network can be global in scope and typically serves a large corporate customer or a government 
agency. A virtual private network (VPN) is a network shared by a set of customers wherein each customer is typically 

so guaranteed services with quality comparable or better than what would be achieved with individual private networks, 
but at lower cost. For example, assume that customer y,/=l ,2, .... in a set of VPN customers uses various service classes 
k. The class or service koi customer j (also called superclass 7) is denoted class (j,k), K=1,2,.../y. In the context of the 
invention, the VPN is implemented by hierarchical virtual partitioning with a two level hierarchy Each call in class Q,k) 
has associated individual characteristics, such as bandwidth required per call, call arrival rate and mean call holding 

55 time. 

As above, the inventive method may be used to determine which links are capable of accepting a call and to 
determine paths through the shared network for routing calls, e.g., the method may be used to determine whether a 
link of capacity Ccan accept a call of class (j,k) in a VPN. Let C y be the nominal capacity allocated to customer / and 
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let CUbe the nominal capacity allocated to class (j,k). Typically, due to the advantage of statistical multiplexing (i.e., 
where, by assuming that information arrives at an outgoing link independently from incoming links, that unutilized time 
varying portions of resources allocated to classes in the network can be used) 



> C 
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C j.1+ C j.2 + 



+C >C; 



Further, let 
by calls from 



n k be the number of calls of class Q,k). The parameter n } will be used to denote the bandwidth occupied 
_ n superclass / Note that n-can be obtained from knowledge of the number of calls in progress of various 
classes in superclass j and from knowledge of the bandwidth used by individual calls of those classes. Alternatively, 
n may be obtained from direct measurements and appropriate smoothing or averaging (over a small prior time interval) 
by techniques well known in the art. The parameter n will be used to denote the bandwidth occupied by calls of all 
classes from all customers. Also, let d jk be the bandwidth requirement for a call of class (j,k). Finally, let 

/^-reservation parameter for superclass ; 

r preservation parameter for class k of superclass j 

FIG. 8 illustrates steps in the inventive method as used in a VPN. in step 810 a request is received to route a call 
of class /cfrom customer /. In step 820, the inventive method determines, if the call is accepted, whether class (j,k) will 
be underloaded, i.e., assuming all calls of class k require bandwidth whether n jk d Jk <Cj k -dj k . 

If the class is underloaded, the "yes" branch of the decision box in step 820 is taken to step 830. Step 830 is a 
decision step in which the inventive method determines, if the call is accepted, whether superclass; will be underloaded, 
/ e whether n/<C r d k . Depending on the determination, either step 831 or step 832 is executed. 

' In step 831, the superclass ; will be underloaded and it is determined whether the link has sufficient available 
capacity for the call. If sufficient available capacity exists (i.e., if n<C-d jk ), the link can accept the call (step 860). 
Otherwise, the link will reject the call (step 862). In step 832, the superclass j will be overloaded. However, if there is 
sufficient available capacity from other superclasses (i.e., if the resources from other classes can be shared) then the 
call may still be accepted provided the call does not borrow or want to share too much capacity from the other super- 
classes. The reservation parameter R } protects underloaded superclasses. Thus step 832 determines if n<C-R f dj k 
and executes either step 860 or 862. 

Returning to step 820, if class (j,k) will be overloaded if the call is accepted, the M no M branch of step 820 is taken 
to step 840. Step 840 is also a decision step in which the inventive method determines (as in step 830), if the call is 
accepted, whether superclass /will be underloaded. Depending on the determination, either step 841 or step 842 is 
executed! In step 841 superclass j will be underloaded and class (j,k) is overloaded. The inventive method then deter- 
mines whether there is sufficient available capacity to accept the call while protecting underloaded classes of customer 
/ In other words, the call is accepted if n<C-r jk -d jfc The parameter r y * has the role of protecting all underloaded classes 
in superclass / from excessive usage by the class k when the class is overloaded. If available capacity exits, the link 
can accept the call (step 860). Otherwise the link will reject the call (step 862). in step 842 superclass] will be overloaded 
as is class Q'M and the inventive method determines if there is sufficient available capacity to accept the call while 
protecting underloaded superclasses and the underloaded classes of customer/ In short, step 842 determines if n<C- 
r k -R-d k Either step 860 or step 862 (i.e., either accepting or rejecting the call on the link) is executed accordingly 
h Thus, in focusing on class (j,k) there are four cases to be considered, depending upon whether the class k and 
the superclass 7 are underloaded or overloaded, in deciding whether newly arriving call of class (j,k) can be accepted 
on the link. The table below summarizes these classes: 



Overload/Underload Status 


Related Step in FIG. 8 


Condition for Accepting Call on Link 


class (j,k) is underloaded and superclass; is 
underloaded 

class (j,k) is underloaded and superclass; is 
overloaded 


831 
832 


accept call if and only if: n<C-d jk 
accept call if and only if: n<C'Rj-d jk 
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(continued) 






Overload/Underload Status 


Related Step in FIG. 8 


Condition for Accepting Call on Link 




class (j,k) is overloaded and superclass j is 


841 


accept call if and only if: n<C-rj k -dj k 


5 


underloaded 








class (j,k) is overloaded and superclass /is 


842 


accept call it and only if: n<C-rj k -Rj-dj k 




overloaded 







10 



A compact equivalent statement of the condition under which a link is capable of accepting or carrying a call is: accept 
a new call of class (j,k) if and only if 



15 



20 



n<C-r jk l(n jk d.^ 

Recall Rj is the reservation parameter whose role is to protect all underloaded customers from excessive use by cus- 
tomer /. Similarly, r //f has the role of protecting all underloaded classes in superclass /from excessive usage by the 
class k when the latter is overloaded. 

As above, parameter fly in general is allowed to depend on the usage by all the superclasses, i.e., all {nj, and also 
on the aggregate parameters of superclass j, Rj=fj{n v n 2i . . rij}. However, as discussed earlier, in the interest of ease 
of implementation, simpler options may be considered. For example, an option is to have three values: 



25 



is large 



30 



Rj=R j9 2 if 



is moderate 



35 



is small 

where R } 1 >R j2 >Rj 3 and Rj v R j2 and R J3 are fixed values. Here, U denotes the set of underloaded superclasses. 
Another option is to have Rj take a constant value independent of the degree of underloadedness. 
The considerations related to the choice of the parameter r Jik are as before. That is, in general, 



45 



r jM= f jJ n P' n j.2>- '> n jjf hkHn : d 7.*> 



50 



Note that advantageously there is no dependence on usage by classes other than those in the same superclass. A 
simpler option is to have three possible values: 

r jtk = r JKI \f £(G./ 
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is large 
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r, k = r jK2 if £ (G. / - «>. id), t) 

5 

is moderate 

r M = r jU if £(G./ 
10 '** 

is small 

where r jk ^r^r^s Here ^denotes the set of underloaded classes in superclass/ A final option is to have retake 
a constant value. 

is Note that path for routing the call through a distributed or centralized VPN can be determined using the inventive 

method of FIGs. 5 and 7, respectively, where steps 530 and 730 are advantageously implemented using the method 
illustrated in FIG. 8. 

This detailed description discloses a method for resource sharing by virtual partitioning. Although the inventive 
method has been described in the context of virtual partitioning of resources, such as bandwidth or capacity, in a 
20 network, those skilled in the art will recognize the applicability of the inventive method to other contexts. For example, 
other network resources, such as buffer space in nodes, may be shared according to the inventive method. It should 
also be noted that the inventive method may be applied to a variety of types of networks including circuit switched and 
packet switched networks. 

The inventive method disclosed herein has been described without reference to specific hardware or software. 
25 Instead, the inventive method has been described in such a manner that those skilled in the are can readily adapt such 
hardware and software as may be available or preferable. 



Claims 

30 

1 . A method of operating a network by sharing resources associated with said network, wherein each class of service 
in a plurality of classes of service is allocated a respective portion of the resources associated with said network, 
wherein a particular class of service operating in said network requires more resources than those allocated to 
said particular class of service, said method comprising the steps of: 

35 

receiving a request to accept a call associated with said particular class of service in said plurality of classes 
of service, and 

accepting said call as a function of a reservation parameter associated with said particular class of service. 

40 2. The method of claim 1 wherein said reservation parameter represents an amount of resources associated with 
said network that cannot be shared by said particular class of service when said particular class of service requires 
more resources than those allocated to said particular class of service. 

3. The method of claim 1 wherein said network is characterized by a network state and wherein said reservation 
45 parameter associated with said particular class of service is a function of said network state. 

4. The method of claim 3 wherein said resources comprise capacity in a link in said network, wherein the capacity is 
shared by a set of calls, wherein each call in said set of calls is associated with a class of service in said plurality 
of classes of service, and wherein said network state characterizes the number of calls associated with each class 

50 of service in said plurality of classes of service. 

5. The method of claim 3 wherein said reservation parameter is also a function of an arrival rate process for calls 
associated with said particular class of service. 

55 6. The method of claim 3 wherein said reservation parameter is also a function of a mean holding time for calls 
associated with said particular class of service. 

7. The method of claim 1 further comprising the steps of: 
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routing said call on path through said network. 

8. The method of claim 7 wherein said network is a centralized network. 

9. The method of claim 7 wherein said network is a distributed network, said method further comprising the steps of: 

if said step of routing is unsuccessful, routing said call on another path. 

10. The method of claim 1 wherein said respective portion of said resources allocated to each class of service is 
sufficient to satisfy a quality of service requirement associated with said each class of service. 

11. A method of operating a network by routing a call on a path through said network, wherein said call is associated 
with a particular class of service, said network comprising links having associated resources, wherein said particular 
class of service is allocated a particular respective amount of the resources associated with each link, and wherein 
said call requires a given amount of the associated resources, said method comprising the steps of: 



receiving a request to route said call through said network, 

identifying a set of links capable of accepting said call requiring said given amount of associated resources, 
wherein a link in the identified set of links is such that either: 1 ) said particular class of service is not overloaded 
and said link has sufficient associated resources to accommodate said call, or 2) said particular class of service 
20 is overloaded and said particular class of service may share, in accordance with a reservation parameter 

I associated with said particular class, resources associated with said link allocated to other classes of service, 

identifying a set of paths on which said call may be routed, wherein each path in said set of paths comprises 
links in the identified set of links, 

selecting a path from said set of paths according to a criterion, and 
25 routing said call on said selected path. 

12. The method of claim 11 wherein said reservation parameter represents an amount of resources associated with 
said network that cannot be shared by said particular class of service when said particular class of service is 
overloaded. 



13. The method of claim 11 wherein said network is characterized by a network state and wherein said reservation 
parameter associated with said particular class is a function of said network state. 

14. The method of claim 11 wherein said network is a centralized network. 

15. The method of claim 1 1 wherein said network is a distributed network, said method further comprising the steps of: 

if said step of routing is unsuccessful, selecting another path from said set of paths according to said criterion 
and routing said call on said other selected path. 

16. The method of claim 11 wherein said particular class of service is one class of service in a plurality of classes of 
service and wherein said network state characterizes the number of calls associated with each class of service in 
said plurality of classes of service. 



17. The method of claim 1 3 wherein said reservation parameter is also a function of an arrival rate process for calls 
45 associated with said particular class of service. 

18. The method of claim 13 wherein said reservation parameter is also a function of a mean holding time for calls 
associated with said particular class of service. 

so 19. The method of claim 11 wherein the particular respective amount of the resources associated with each link allo- 
cated to said particular class of service is sufficient to satisfy a quality of service requirement associated with said 
particular class. 

20. A method of operating a hierarchical network by sharing resources associated with said network, wherein said 
55 hierarchical network comprises levels, wherein each level has associated classes, wherein each associated class 

is allocated a respective portion of the resources associated with said network, said method comprising the steps of: 

receiving a request to accept a call associated with a particular level, and 
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accepting said call as a function of at least one of: a reservation parameter associated with said particular 
level or a reservation parameter associated with said particular class associated with said particular level. 

21. The method of claim 20 wherein said hierarchical network is characterized by a network state and wherein said 
reservation parameter associated with said particular level and said reservation parameter associated with said 
particular class associated with said particular level are each a function of said network state. 
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FIG. 3 
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